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Abstract 

The Microwave Anisotropy Probe (MAP) mission 
utilized a strategy combining highly eccentric 
phasing loops with a lunar gravity assist to provide a 
zero-cost insertion into a Lissajous orbit about the 
Sun-Earth/Moon L2 point. Maneuvers were executed 
at the phasing loop perigees to correct for launch 
vehicle errors and to target the lunar gravity assist so 
that a suitable orbit at L2 was achieved. This paper 
will discuss the maneuver planning process for 
designing, verifying, and executing MAP s 
maneuvers. This paper will also describe how 
commercial off-the-shelf (COTS) tools were used to 
execute these tasks and produce a command sequence 
ready for upload to the spacecraft. These COTS tools 
included Satellite Tool Kit, MATLAB, and Matrix-X. 

Introduction 

The MAP mission was launched on June 30, 2001 
from Cape Canaveral on a Delta-II 7425-10 
expendable launch vehicle. The spacecraft was 
separated into a highly elliptical orbit with ^ an 
inclination of 28.7° and a C3 energy of —2.6 km / s 
MAP remained in this “phasing” orbit for three full 
loops before encountering the Moon and receiving a 
gravity assist to the Sun-Earth/Moon L2 Lagrange 
point (1.5 million kilometers from the Earth, in the 
direction opposite the Sun). From its Lissajous orbit 
about L2, MAP will measure the temperature 
fluctuations of the cosmic microwave background, 
the radiant heat left over from the Big Bang. MAP is 


a follow-on mission to NASA’s Cosmic Background 
Explorer (launched in 1989). 

After separation from the launch vehicle, MAP was 
required to perform several perigee maneuvers during 
the phasing loop portion of the mission in order to 
accurately target the lunar encounter. Overall, seven 
maneuvers were planned to occur before the lunar 
encounter - three perigee maneuvers, three 
engineering bums (which occurred at the three 
phasing loop apogees), and a final perigee correction 
maneuver (PfCM) 18 hours after the final perigee. 
After the lunar encounter, two mid-course correction 
maneuvers (MCCM) were required to fine-tune the 
trajectory. The end result of these maneuvers was to 
achieve a Lissajous orbit that met all MAP's mission 
requirements'. Since the zero-cost insertion into the 
Lissajous orbit, two stationkeeping maneuvers (SKI 
& SK2) have been performed to keep MAP orbiting 
around L2. Future stationkeeping maneuvers will be 
required every three months for the life of the 
mission (two years, with a goal of four years). A 
picture of MAP’s trajectory can be seen in Figure 1. 
Complex planning and coordination was needed to 
ensure the success of these maneuvers as the 
maneuver products crossed many disciplines (Table 
1). While the process described herein applies to all 
maneuvers, the following discussion will be 
concerned with the time-critical perigee maneuvers 
and the PfCM. 


Table i; MAP Maneuver Team & Responsibilities 


MAP Subsystem 


Maneuver Planning Activities 


Trajectory Design 


Attitude Control System 
(ACS) 


Propulsion 


✓ Defined time, magnitude, and attitude tor all maneuvers 

/ Verified maneuver a gainst mission constraints — - — 

✓ Executed maneuvers in various simulators prior to upload to MAP 

✓ Computed attitude control dutycycles for thrusters 

y Verified maneuver against attitude constraints _ — ; — ; — — 

/ Provided state of propulsions system (tank pressure, tank temperature, fuel remaining) 
/ Monitored performance of propulsion system _ 


Navigation 


✓ Calculated orbit determination solution 

V Delivered acquisition data to tracking assets 


Thermal 


■/ iTvajuated mtitiiHp nrofile for sola r intrusion onto MAP's i nstrument 
./ n„^i,iarpH attitude n rofile to ensure sufficient power for maneuv er 

* — : “ : ; CZ r-x r- w 1 1 THD c 


Power 

Ground Systems 


y Scheduled tracking data periods with DSN and TDRS 
/ Generated attitude profile and command sequence tor upload to MAP 


MAP Systems Engineer 


/ Provided oversight of entire process 
/ Correlated solar activity levels with threat potential to MAP during maneuvers. 


* Flight Dynamics Engineer, Guidance, Navigation, and Control Center Senioi Membei A1AA 

* Attitude Control System Engineer, Guidance, Navigation, and C ontrol Center 



Lunar Orbit 


L2 Lissajous 
Orbit 




Figure 1: MAP Trajectory to L2 (Solar Rotating Coordinates) 


MAP Propulsion System 

The MAP spacecraft carries a mono-propellant 
hydrazine system with a beginmng-of-life, full tank 
load of 72.57 kg of fuel. Connected to the tank are 
eight, one-pound (4.45 Newton) thrusters which are 
grouped into three primary firing modes: +X, +Z, and - 
Z (referenced to the body axes). The +X thrusters 
consist of thrusters 5 & 6 (oriented along the +X body 
axis) and thrusters 7 & 8 (oriented 15° off of the +X- 
axis, towards +Z). Due to the orientation of thrusters 7 
& 8, performing maneuvers utilizing thrusters 5, 6, 7, & 
8 requires pitching the spacecraft 7.5° (about the +Y 
axis) to align the resultant thrust vector along the 
desired thrust direction. The +X thrusters are used for 
the perigee maneuvers and the PfCM. A +Z maneuver 
uses thrusters 3 & 4 (oriented 30° off of the Z-axis) and 
a — Z maneuver uses thrusters 1 & 2 (orientated 10° off 
of the Z-axis, towards -X). The ±Z thrusters are used 
for the MCCM and SK maneuvers. During any 
maneuver, all thrusters are included in the control loop 
to maintain pointing and stability. The layout of MAP’s 
thrusters can be seen in Figure 2. A more detailed 
discussion of MAP’s propulsion system can be found in 
Reference 2. 



Figure 2: MAP Thruster Layout 


Maneuver Planning Process 

As mentioned above, MAP s maneuver planning 
required input and verification from many different 
disciplines. At the same time, the process also involved 
bringing together many different pieces of software, 
many of which were commercial off-the-shelf (COTS) 
products. Satellite Took Kit’s (STK) Astrogator 
module, developed by Analytical Graphics, Inc., was 
used as the major tool for MAP’s trajectory design 
activities. Astrogator was used for the high-fidelity 
trajectory modeling and maneuver planning. STK's 
Visualization Option (VO) was used to represent the 
trajectory in 3-dimensional space while viewing such 
objects as sensor cones and attitude orientation. 
MATLAB, developed by The MathWorks Inc., was 
used to create the Quaternion Generator (QuatGen) tool 
for processing the maneuver attitude. MATLAB was 
also used extensively as a data reduction tool by the 
trajectory design team. Matrix-X, originally developed 
by Integrated Systems but now distributed by The 
MathWorks Inc., was used to create HiFi, a high 
fidelity, software-only simulator of the MAP attitude 
control system. The final major component was FlatSat, 
a real-time hardware-in-the-loop simulator, which used 
engineering test units (ETU’s), ground system 
terminals, and MAP flight software loaded to the 
ETU’s to simulate operations on the spacecraft. A 
simplified form of the process is shown in Figure 3. 
The major inputs (e.g. impulsive maneuver plan, orbit 
determination state, and the propulsion state) were 
passed into Astrogator for an initial finite maneuver 
plan. Furthermore, great care w r as taken to make sure all 
components of the process used the same database 
information. This information included thruster unit 
vectors, propulsion blowdown parameters, etc. Output 
from this plan was passed through QuatGen to create a 
command quaternion table (CQT) - a time history of 
the desired attitude for the maneuver. This data was 
then passed into both simulators, HiFi and FlatSat, to 
simulate the maneuvers. The difference in these 
simulators is part speed and part fidelity. HiFi performs 
a fast simulation of the maneuver as it pertains to the 



ACS subsystem. FlatSat, on the other hand, is a real- 
time simulator that was used to test all of the maneuver 
commands on the ground before they were uploaded to 
the spacecraft. After each simulation, Astrogator was 
used to “close the loop”, processing outputs from each 
simulator to verify that no significant change to the 
nominal trajectory occurred. The results of these 
simulations were made available to the remaining 
subsystems for concurrence. Prior to each maneuver, a 


command authorization meeting (CAM) was held 
during which the maneuver plan was examined in 
detail. After it was determined that all subsystems were 
in agreement with the plan, each subsystem lead 
signed-off on the final maneuver plan. The detailed 
version of this process is showii in Figure 4. The 
following sections of the paper will discuss these 
different tools and how they were used in this process. 



Figure 3: Maneuver Planning Process 
















The timing for this process started with the delivery of 
the orbit determination solution 23 hours prior to 
maneuver ignition (M-23). The trajectory team used the 
current orbit and propulsion states to produce a 
preliminary finite maneuver plan. This plan was used to 
deliver products at M-20 for the HiFi and FlatSat 
simulation. The results from the HiFi and FlatSat 
simulations were completed at M-19 and M-16 hours, 
respectively. After verification of the simulations by the 
trajectory design team, data was sent to the other 
subsystems for validation at M-13 hours. Typically, the 
command authorization meeting (CAM) was held at M- 
11 hours, at which time the maneuver plan was 
discussed with all subsystem representatives present. 
The Automatic Time Sequence (ATS), the list of 
commands necessary to perform the maneuver 
(including the CQT), was uploaded to MAP following 
the successful completion of the CAM. After 
verification of successful transmission to MAP, the 
ATS was enabled. The first commands from the ATS 
were typically executed at M-2 hours. 

STK/Astrogator 

STK’s Astrogator module was the primary tool used for 
MAP’s trajectory design. The MAP team used 
Astrogator version 4.1.1 on a Windows NT platform for 
all of the trajectory design and maneuver planning 
activities. The maneuver design process began with the 
receipt of an orbit determination state from the 
Navigation team. Tracking data from the Deep Space 
Network’s (DSN) ground station was processed using 
the Goddard Trajectory Determination System (GTDS) 
to produce an STK-formatted ephemeris file. An orbit 
state from the ephemeris file was ingested into STK’s 
Astrogator module to use as the initial state. The 
Propulsion engineer was responsible for supplying the 
current propulsion state - fuel remaining and tank 
pressure. The tank temperature was not used as it was 
determined to be a second order effect. Important 
database information was also included as inputs. This 
included thruster unit vectors, measured prior to launch, 
along with the thruster performance, in terms of force 
(Newtons) and specific impulse (Isp, in seconds). The 
thruster performance was delivered in the form of 
blowdown curves as a function of tank pressure. For 
MAP, it was decided that each thruster would keep the 
same performance level and calibration would be 
performed on the entire system, as opposed to 
calibrating each thruster. Other database information 
included the MAP dry mass, tank volume, fuel density, 
solar radiation pressure area, & coefficient of 
reflectivity (C R ). With MAP’s mission requirement of 
perigee heights greater than 500 km, atmospheric drag 
during the phasing loop perigees was not considered. In 
fact, MAP’s June 30 th launch date and a nonunal launch 


vehicle insertion ensured that no perigee height was less 
than 1000 km. 

After inclusion of the orbit determination and 
propulsion states, the impulsive maneuver plan in 
Astrogator was converted to a finite maneuver plan. All 
MAP trajectory planning was performed using 
impulsive maneuvers. The impulsive to finite 
transformation only occurred in preparation for 
executing a maneuver. For any finite maneuver, a 
“thruster set” (+X, +Z, or -Z as defined above), 
coordinate frame, Euler angle rotation, start time, and 
duration were selected for the particular maneuver. 
Regardless of the maneuver type, all maneuvers were 
planned such that the Sun remained in MAP’s digital 
sun sensor (DSS) field of view. The DSS was used as a 
backup rate source in the event of an Inertial Reference 
Unit (IRU, or gyro) failure. The DSS field of view is 
formed from two sensors mounted on the +Z side of the 
spacecraft. Each sensor has a 64° x 64° rectangular 
field of view. The sensors were mounted ± 29.5° off of 
the +Z axis to create a usable field of view of 50° by 
110°. The ±Z maneuvers keep the Sun in the field of 
view by default, since these maneuvers are performed 
at an attitude where the +Z-axis is 19° off of the MAP- 
Sun line - the nominal attitude for stationkeeping 
maneuvers. The +X maneuvers were slightly different. 
These maneuvers were planned in a “Velocity-Sun’ 
frame. First, the MAP body X-axis is aligned with the 
velocity vector. Then, the Z-axis is orientated towards 
the Sun while staying in the plane made by the velocity 
vector and the MAP-Sun vector. Then, MAP was 
pitched 7.5° about the Y-axis to align the resultant +X 
thrust vector with the velocity vector (Figure 5 \ as 
displayed using STK VO. In this alignment, the Sun 
remains in the center of the short axis of the DSS field 
of view while it travels along the long axis of the field 
of view. During the first perigee (PI) maneuver, the 
Sun traveled through more than half of the field of 
view. Shortly after launch, MAP instrument personnel 
changed the maneuver requirement limiting the DSS 
FOV to 50° by 90° due to the potential for Sun 
impingement on the instrument’s main reflector at the 
extremes of the field of view. The QuatGen program 
was modified to handle this late change. Regardless, the 
trajectory team analysts were able to model this field of 
view by creating a sensor object in STK and attaching it 
to the vehicle. Viewing the sensor dynamics during 
maneuvers in STK’s VO module was indispensable in 
regards to analyzing the maneuver. 


+Y 



Figure 5: MAP Attitude for +X Maneuvers 

Once the attitude was properly set, a differential- 
correction targeting scheme was executed to determine 
the optimal start time and duration for the burn. The 
targeting was performed using two control variables 
(start time and duration) and two goals (lunar encounter 
parameters). After the scheme converged, product 
generation for the attitude simulations could begin. One 
output of this process was a one-lme file containing 
data for the HiFi and FlatSat simulations. This file 
contained the maneuver start time, the maneuver 
duration, the maneuver average thrust (HiFi did not 
have a blowdown model for thrust), the spacecraft mass 
prior to ignition, and the tank pressure prior to ignition. 
All unit issues were resolved beforehand and were 
documented in an interface control document (ICD) . 
The remaining products were created using QuatGen — 
a MATLAB utility used to output the attitude 
quaternions to control to during the maneuver. All +X 
maneuvers were initially planned using only thrusters 5, 
6, 7, & 8 with a dutycycle of 100%. The HiFi and 
FlatSat simulations modeled the attitude dynamics and 
would provide the appropriate thruster dutycycles for 
all eight thrusters. This included off-pulsing by the +X 
thrusters and on-pulsing by thrusters one through four. 
Similarly, the ±Z maneuvers were initially planned 
using only thrusters 3 & 4 or 1 & 2, respectively. The 
attitude simulations provided the appropriate dutycycles 
for those maneuvers as well. 

After the HiFi and FlatSat simulations were performed, 
Astrogator was used to close the loop by feeding results 
from those simulations back into trajectory plan and 
examining the results. The simulation results included 
the dutycycle thrusting of all eight thrusters, an attitude 
history file, and an adjusted bum duration. The attitude 


history contained the estimated quaternions that the 
ACS controlled to during the simulation. As MAP 
needs to follow the velocity vector during the perigee 
bum, the ACS must continually re-point the spacecraft. 
This attitude history file simulates MAP’s “crab- walk" 
through the perigee maneuver. The adjusted bum 
duration results from the programming of the ACS. For 
example, during a +X maneuver, thruster 4 fired at a 
40% dutycycle to maintain stability. As thruster 4 has a 
thrust component opposite the maneuver direction, the 
maneuver was lengthened on-board the spacecraft to 
compensate. An Astrogator simulation w'as performed 
to evaluate the effects of the dutycycle thrusting, the 
estimated attitude, and the adjusted maneuver time. 
This evaluation was performed by way of examining 
the downstream effects of the simulated maneuver on 
subsequent maneuvers. 

MATLAB - QuatGen 

Since MAP’s on-board computer was not designed to 
generate the necessary control quaternions needed 
during maneuvers, ground processing was required to 
provide the attitude to MAP and the on-board computer 
was modified to accept this data. QuatGen was built by 
Rick Harman of NASA’s Goddard Space Flight Center 
to meet this requirement. QuatGen was developed using 
MATLAB 5.1 and was run on a Windows NT platform. 
QuatGen inputs include spacecraft ephemeris data and 
solar ephemeris data. The spacecraft ephemeris can be 
from a NASA/GSFC Code 500 ephemeris, a STK 
ephemeris, or propagated from a Keplerian orbit state. 
Acceptable solar ephemeris inputs are a NASA/GSFC 
Code 500 Solar/Lunar/Planetary file or analytical from 
the Astronomical Almanac. The remaining inputs 
include the time span in question, the spacecraft 
attitude, and the frequency of quaternion output. 
Typically, QuatGen was executed to create data 
spanning from one hour prior to ignition to twelve 
hours after burnout. Data was created for a long post- 
maneuver period to ensure that sufficient attitude data 
was on-board the spacecraft in the event of a 
contingency (e.g. delaying the maneuver). The 
spacecraft attitude was entered in the form of an Euler- 
sequence rotation. QuatGen was programmed to 
compute MAP’s quaternions in the “Velocity-Sun" 
frame described above where a single 7.5° pitch about 
the Y-axis was required to provide the nominal attitude. 
In the event of a thruster failure, QuatGen (and 
Astrogator) could change to a two-thruster mode (using 
either thrusters 5 & 6 or 7 & 8) while choosing the 
appropriate pitch angle - 0° or 15°, respectively. A new 
quaternion was computed for every 1 degree change in 
the velocity direction during the perigee pass. During 
MAP’s phasing loops, this equated to a new' quaternion 
every 30 seconds at perigee. A sample from the 
QuatGen graphical user interface (GUI) for data entry is 


shown in Figure 6. QuatGen was modified early in 
2001 to account for the limits of the DSS field of view 
constraints. If, by orbit geometry, the Sun was not in 
the field of view at the beginning of the desired time 
span, QuatGen would set the initial quaternion at the 
limit of the field of view (45° off of the Z-axis). Then, 
QuatGen kept this attitude constant until the field of 
view constraint was met by the passage of MAP 
through perigee. A sample of the QuatGen output, 
showing this capability, is shown in Figure 7. 
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Figure 6: QuatGen Data Entry GUI 
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Figure 7: QuatGen Quaternion Plot 

Three files are output from QuatGen. An ephemeris file 
(QuatGenEph) contains the spacecraft state (position & 
velocity) and solar state (position only). A time history 
of the quaternions is contained in the QuatGenQuats 
file. The CQT file contains the quaternions in a format 
suitable for upload to MAP. These three files were 
delivered to the ACS engineers for inclusion in the HiFi 
and FlatSat simulations. All output files are written in 
simple ASCII text. 


Matrix-X - HiFi 

The ACS team built and maintains the High Fidelity 
(HiFi) simulator. HiFi is a software-only simulation of 
the spacecraft control system and dynamics, and was 
developed using the Matrix-X family of simulation and 
analysis tools. It includes sensor and actuator models, 
plus external force and torque models, including a 
simple orbit propagator. HiFi runs faster than real time, 
and can simulate any of the control modes and mode 
transitions. With the proper initialization and script 
files, multiple modes and maneuvers can be simulated, 
including multiple commanded attitudes and timed 
sequences of commands. The files needed to initialize 
the simulation, and the output of the simulation results, 
are described in the MAP Maneuver Operations Team 
Interface Control Document 5 . The HiFi simulation and 
the use of the Matrix-X tools in designing, analyzing, 
and simulating the MAP ACS is described in more 
detail in Reference 6. The HiFi simulation can calculate 
the velocity impulse delivered to the spacecraft, but 
does not include a thruster blowdown model The more 
accurate thruster model is left to Astrogator and to the 
FlatSat real time simulator. 

There were initialization files set up for each maneuver 
to be performed, based on files previously created for 
running the HiFi simulation in support of software 
testing and simulation analysis. In addition, the 
Trajectory team provided ephemeris and attitude files, 
and a file containing maneuver start, duration, and 
initial condition information such as fuel tank pressure. 
A separate input script was written to read in these files 
and use their data to initialize the HiFi simulation. The 
timing of events in the simulation (like the de-spin from 
the compound spin science mode or the slew to the bum 
attitude) was controlled by manually modifying a part 
of the input script to match the timing in the ATS 
template for a given maneuver. 

Once the simulation was run, separate MathScript files 
were run to create the necessary output files. There was 
a maneuver summary file that included information on 
duty cycles, estimated AV delivered, attitude errors, and 
bum duration. Also created were files containing the 
attitude profile and thruster command profile in a 
format that was readable by STIC/Astrogator. Plots of 
sun angles, attitude errors, system momentum, and 
other relevant data were generated. These were FTP’d 
to a central location for use by the subsystem engineers 
for verification. 

FlatSat 

FlatSat is a real-time, hardware-in-the-loop Engineering 
Test Unit (ETU) flight software test platform. It is used 
to test interfaces to flight components, and to test the 



flight software in a realistic operations environment. 
The flight software is loaded to ETU's of the flight 
processors and flight boards, and interfaces with the 
ground command console. There is a Hybrid Dynamic 
Simulator (HDS) attached that simulates the spacecraft 
dynamics, sensors, actuators, and external environment. 
This facility was also used for acceptance-level flight 
software testing. For the MAP project, the control 
center consoles were hooked to FlatSat, and FlatSat was 
also used as a spacecraft mission simulator. Power 
subsystem racks were also integrated to FlatSat. 

The interface to FlatSat was just like the flight 
operations interface, and all simulations had to be set up 
and run with flight-like procedures. The data was 
collected in sequentially printed output files, which 
were then post-processed with the HiFi simulation 
toolset (specifically, Xmath and custom-build data 
processing scripts) to generate plots and other data. 
Since FlatSat had ETU’s of the flight processors and 
actual ground consoles, the ATS commands and the 
CQT needed for each maneuver, as well as the Failure 
Detection and Correction (FDC) configuration, could 
be tested to verify timing and configuration issues that 
aren’t tested in HiFi. 

There were several files needed by FlatSat for a 
maneuver simulation to be run. The navigation team 
would take the trajectory data and the ATS template 
and generate a flight ATS for testing on FlatSat. In 
addition, for the long perigee maneuvers, the trajectory 
team generated CQT would be FTP’d to the FlatSat 
terminal for use in the test, after the navigation team 
had verified the format. The HiFi initialization file was 
also sent to the FlatSat terminal to be used for 
initialization of the HDS. A procedure was written to 
initialize and start the HDS and FlatSat. This script also 
read and loaded the ATS and the CQT to the ETU 
spacecraft processor. After the initial values were 
verified, the ATS would be enabled, and the test would 
run in real time. This would verify the flight software 
configuration and timing, the commanded attitude 
profile, and also the effects of the pressure blowdown 
during the maneuver. All processor and HDS data were 
captured in sequential print files by the ground system. 

At the end of the test, the data files would be FTP’d to 
the HiFi machine, where they could be ingested, 
plotted, and analyzed using script files generated for 
software testing. The output files were the same as for 
the HiFi simulation. These files were also sent to a 
central location for use by other subsystems. Most 
importantly, the attitude and thruster command profile 
files were fed back into STK/Astrogator to generate a 
“best estimate” prediction of the upcoming maneuver. 


Command Authorization Meeting 

The final step in the process was the Command 
Authorization Meeting (CAM). At this meeting, all the 
simulation results were presented to the project, 
including systems engineers, scientists, and other 
subsystems. The verification of predicted fuel use, 
maneuver duration, attitude, and AV was shown, 
indicating good agreement between the trajectory, ACS, 
and propulsion subsystems. The contact timelines with 
the Deep Space Network (DSN) and the Tracking and 
Data Relay Satellite System (TDRSS) were discussed. 
Briefings on the current space weather and predicted 
radiation levels for the perigee passes were also 
included. In addition, an overall timeline, from loading 
the ATS and CQT to final post-maneuver sating of the 
propulsion system, was reviewed. Once the team was 
satisfied with the results, and understood the maneuver 
and possible contingencies and appropriate response, 
the subsystem lead engineers would sign an 
authorization form allowing the maneuver to proceed. 

Performance 

As mentioned above, one measure of performance for 
this process is to examine the errors induced 
downstream from feeding the attitude simulations back 
through Astrogator. In other words, what is the 
downstream AV penalty for the P2 and P3 maneuvers 
due to modeling errors at PI? This procedure was 
filtered downstream for each maneuver. The P2 
maneuver induced an error in the P3 maneuver. The P3 
maneuver induced an error in the PfCM while the 
PfCM induced an error in the MCC. In Table 2, the 
downstream induced errors are shown for each of the 
phasing loop maneuvers. In all cases, the error is small, 
less than 30 cm/s. The PI and P2 induced errors are 
small because their corrections are being made at 
subsequent perigees (the optimal location for energy 
changes in an orbit). The error induced from P3 is 
added at the PfCM, executed 18 hours after perigee. 
This location is much less efficient than executing a 
maneuver at perigee. The induced error from PfCM 
(corrected at MCC, 7 days after lunar encounter) is 
largely due to the amplifying effect of the lunar 
encounter 5 . A discussion of the observed (calibrated) 
execution errors is also a way to evaluate the 
performance of the process. However, the observed 
errors contain the actual propulsion system performance 
as well as any orbit determination uncertainties and this 
goes beyond the modeling described above. As it were, 
this calibrated performance for the MAP system for all 
maneuvers was well within 5%. This result was 
computed using a thrust scale factor in order to fit the 
observed data to the predicted data. 



Table 2: Performance of Planning Process 


Maneuver 

HiFi Induced 
Error 
(cm/s) 

FlatSat Induced 
Error 
(cm/s) 

PI 

1.0 

1.1 

P2 

r -1.5 

-1.5 

P3 

26.3 

27.9 

PfCM 

18.1 

18.1 


Conclusions 

The greatest measure of the success of this maneuver 
planning process is that MAP successfully passed the 
Moon on July 30, 2001, at an altitude of 5000 km. This 
gravity assist allowed MAP to enter a small amplitude 
Lissajous orbit about L2 without any insertion 
maneuver. At this time, MAP has completed its second 
stationkeeping maneuver and is well on its way to a two 
year mission at L2. This was made possible by the use 
of the COTS tools described above (STK, MATLAB, 
Matrix-X) and the hard work and diligence of the MAP 
Maneuver Team. The authors would like to 
acknowledge the hard work by the Navigation team 
lead. Dale Fink (Computer Sciences Corporation), and 
the Propulsion subystem lead, Gary Davis 
(NASA/GSFC). 
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